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(an  exercise  in  Z  specification) 

Author  t  C-  O’Halloran  .  ■ 
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Summary 


The  specification  of  a  software  repeater  m  a  language  known 
as  Z  is  presented.  The  specification  is  then  refined  into  an 
implementation  in  the  C  programming  language.  The 
correctness  of  the  implementation  is  shown  by  means  of  proof 
obligations  and  the  program  analysis  tool  flalpas.  The  C 
implementation  was  compiled  and  ran  successfully  on  a  58010 
processory^ 
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INTRODUCTION 


This  memarandum  arose  from  a  problem  posed  by  the  panel  on  trustworthy 
computing  technology  under  the  auspices  of  the  technical  co-operation 
programme.  This  panel  posed  a  simple  problem  in  the  specification  of  a 
process  introducing  concurrency#  the  software  repeater.  The  process 
receives  characters  and  at  some  later  time  transmits  them.  Since 
characters  may  arrive  at  a  rate  greater  than  the  rate  at  which  they 
can  , be  transmitted  an  internal  buffer  is  necessary. 


Solutions  of  this  problem  illustrate  techniques  currently  available 
for  the  formal  specification#  design  and  implementation  of  a 
concurrent  process.  The  reason  for  choosing  this  particular  problem 
was  that  if  it  could  not  be  solved  easily  then  it  would  not  be 
feasible  to  use  formal  methods  for  more  realistic  problems.  However 
formal  methods  would  not  normally  be  applied  to  a  problem  like  this  as 
it  is  so  simple. The  following  specification  was  given: 

1.  Everything  received  by  the  repeater  is  re-transmitted,  eight 
bit  character  by  eight  bit  character. 

2.  Only  received  characters  are  transmitted. 

3.  The  internal  buffer  used  to  store  the  cl;iaracters  must  be 
finite. 

4.  Every  error  condition  must  be  characterised#  first  by 
writing  to  an  alternative  port  and  then  by  halting. 

5.  Any  simple  processor  may  be  used  to  implement  the  repeater. 

The  repeater’s  design  and  implementation  must  allow  its 
ports  to  run  at  a  range  of  speeds. 

This  memo  falls  into  three  main  sections.  The  first  section  deals  with 
the  specification  of  the  repeater  in  Z.  In  this  section  the  first  two 
assertions  about  the  repeater  are  shown  to  be  valid.  The  other 
assertions  such  as  the  precise  size  of  the  buffer  are.  design  criteria. 
In  the  second  section  a  design  for  the  repeater  is  developed  and 
proofs  concerning  the  correspondence  between  specification  and  design 
are  conducted.  The  third  section  deals  with  the  implementation  of  the 
design  in  C  for  its  eventual  compilation  and  running  on  a  processor. 
The  C  implementation  is  then  translated  into  a  language  called  HALPA5 
IL  enabling  it  to  be  analysed  for  various  purposes.  There  is  one 
appendix  listing  the  flALPAS  IL  model  with  comments  on  translation. 

riALPAS  IL  is  a  program  modell ing  language  based  upon  directed  graphs, 
for  a  description  of  the  language  see  tRTP  371.  The  equivalence 
between  directed  graphs  and  regular  expressions  allow  abstract 
interpretations  to  be  performed  in  various  regular  algebras.  One 
analysis  in  particular  yields  the  semantic  relationship  between  the 
initial  and  the  final  state  of  a  program.  In  conjunction  with  a  form 
of  verification  condition  generator  and  a  simplifier,  an  automatic  and 
independent  proof  that  a  program  satisfies  a  specification  may  be 
obtained.  For  an  overview  see  tBramson  85,  87].  The  ability  to  verify 
an  IL  model  by  the  use  of  assertions  gives  HALPAS  some  of  the 
properties  of  formal  specification  systems  such  as  GYPSY  or  EVES, 
[Smith  87#  Pase  83#  Craigen  BB]. 

For  a  description  of  Z  and  associated  refinement  see  [Hayes  8B#  Spivey 
86#  Sufrin  86#  Sanders  86#  Sorensen  86].  Z  is  based  on  elementary  set 
theory  which  provides  a  readily  understandable  basis  for 
specification.  It  is  structured  using  the  language  of  schemas,  which 
supports  an  incremental  style  of  presentation  and  is  explained  in 
detail  in  [Horgan  841.  Z  and  the  development  method  originated  from 
the  Oxford  Programing  Research  Group. 
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Data  Objects 

The  fact  that  the  characters  are  represented  by  eight  bit  characters 
is  irrelevant  to  the  specification  at  this  level.  Therefore  the  set  of 
all  possible  characters  is  introduced  as  a  given  set. 

[Char ] 


To  describe  the  behaviour  of  the  process  sequences  of  characters 
which  will  record  the  history  of  the  characters  input  or  output  are 
introduced  by  a  schema  called  HISTORY. 


HISTORY _ ' 

input_trace.  output_trace  :  seq  Char 

* 


Uhen  a  character  is  received  then  the  identifier  input_trace  must  be 
updated,  similarly  for  output_trace.  To  denote  some  change  in  an 
identifier  a  prime  is  appended  to  it.  schema  name  which  is 

primed  means  that  the  identifiers  declared  within  it  are  primed  and 
the  meaning  of  a  schema  which  contains  a  schema  name  is  given  by 
expanding  the  included  schema.  Thus  a  change  in  the  recorded  history 
0-^  input  and  output  is  denoted  by  the  following  schema. 


^fiHISTORY 

HISTORY 
HISTORY’ 


input_trace  prefix  input_trace’ 
output_trace  prefix  output_trace’ 


The  predicate  below  the  line  guarantees  that  the  behaviour  of  the 
process  is  a  continuation  of  the  previous  behaviour.  For  example 
input_trace  cannot  be  updated  by  making  it  a  shorter  sequence.  Note 
that  there  is  an  implicit  conjunction  between  predicates  on  different 
lines.  Finally  an  update  to  the  internal  buffer  is  defined  by 

^BUFFER _ _ 

buffer,  buffer'  :  seq  Char 


Repeater  Operations 


The  maximum  sire  for  the  buffer  is  max  :  N.  The  initial  and 
intermediate  states  of  the  repeater  are  given  by  the  initial  and  final 
states  of  the  operation  RECITE-  The  schema  RECITE  specifies  the 
behaviour  of  the  repeater  before  one  of  two  error  conditions  occur. 

The  handling  of  errors  in  Z  is  specified  Separately  by  another  schema, 
in  this  case  OWERFLOU  which  is  described  later.  One  error  condition  is 
that  a  character  collected  at  the  input  port  has  been  overwritten  by 
another  incoming  character.  To  model  this  a  set  of  values  of  a  status 
register  for  the  input  port  is  introduced  before  the  operation.  The 
second  error  condition  is  when  the  internal  buffer  overflows- 
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Inputjstatus_re9ister  *  •Cready.  collects  overflow> 

RECITE  _ 

^BUFFER 

HISTORY 

status’  :  Input_status_re9ister 


input_trace  =  <>  a  output_trace  =  <)  a  buffer  =  <> 
input_trace’  =  output_trace’ ''buffer  ’ 

(wbuffer’  2  max  v  status’  =  overflow) 


This  operation  defines  the  initial  state  of  the  buffer  and  traces  to 
be  equal  to  the  empty  sequence.  Buffer  overflow  occurs  when  the  buffer 
contains  'max’  characters-  This  9uarantees  that  the  repeater  does  not 
lose  the  last  character.  The  final  state  constrains  the  input  trace  to 
be  the  concatenation  of  the  output  trace  with  the  buffer. 


When  an  error  occurs  it  must  be  reported  to  the  external  world-  Output 
communications  are  denoted  by  decorating  an  identifier  by  a  shriek. 
'!’.  Since  a  report  is  to  be  communicated,  a  set  of  reports  must  be 
introduced.  The  specification  does  not  say  what  .they  are  only  that 
they  exist.  Two  error  reports  from  this  set  arfe  declared  afterwards. 


[Report ] 

buffer_Qverf low,  bit_overflow  :  Report 

OUERFLDU  _ 

buffer’.  input_trac8’ .  output_trace’  :  seq  Char 
rep!  ;  Report 

status’  s  Input_status_register 


input_trace’  =  output^trace* ''buffer ' 

((wbuffer’  2  max  a  rep!  =  buffer_overf low ) 

V 

(status’  =  overflow  a  rep!  =  bit  overflow  a  ^buffer ’ ^max  ) 

) 


The  schemas  RECITE  and  OVERFLOW  may  be  conjoined  to  give  a 
description  of  the  repeater  with  error  handling. 

REPEATERq  4  RECITE  a  OVERFLOW 

To  complete  the  specification  an  operation  to  transmit  the  characters 
held  in  the  buffer  must  be  defined- 
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.CLEARDQUN  _ 

buffer  :  seq  Char 

^HISTORY 


input_trace’  =  input_trace 
input_trace  =  output_trace~buffer 
5  output_trace’  =  output_trace''buffer 


The 'total  specification  of  the  repeater  is  siven  by  composing  the 
operations  REPEATERg  and  CLEARODUN. 

REPEATER  i  REPEATERg  J  CLEARDOUN 

The  English  specification  given  in  the  introduction  is  not  complete 
with  regard  to  errors.  It  states  that  after  reporting  an  error  the 
repeater  must  halt*  yet  earlier  it  stated  that  everything  received 
must  be  re~transm itted.  This  specification  gives  a  clear  and 
unambiguous  description  of  the  software  repeater.  In  addition 
properties  of  the  formal  description  may  be  derived. 

Satisfaction  of  Requirements 

To  show  that  the  specification  meets  the  relevant  requirements  the 
following  theorem  is  proved. 

REPEATER 

input_trace’  =  output_trace’ 


Proof : 


By  the  definition  of  3  REPEATER  is 

REPEATER  _ 

buffer  :  seq  Char 

^HISTORY 

status,  status*  :  Input_status_register 
rep!  :  Report 


input_trace  =  <)  a  output_trace  “  ( >  a  buffer  =  <> 

3  in.  out.  buff  :  seq  Char  • 
in  =  out''buff 

((ebuff  2  max  a  rep!  =  buffer_overf low  )  v 
(status’  =  overflow  a  rep!  *  bit_overflow  a  «»buff  *  max)) 
input_trace’  =  in  a  output_trace'  =  out~buff 

which,  by  elimination  of  the  existential  quantifier,  simplifies  to 

input_trace’ .  output_trace'  ;  seq  Char 
status,  status’  :  Input_rBgister‘_port 
rep!  :  Report 


input_trace’  =  output_trace’ 


which  contains  the  required  predicate.  D 
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THE  DESIGN 


Ref i nement 


In  the  previous  section  a  formal  unambisuous  specification  of  the 
repeater  uas  developed.  The  next  stage  is  to  produce  a  design  which  is 
a  lower  level  representation  of  the  specification.  The  design  arises 
when  the  specification  is  refined  into  a  small  number  of  components. 
Each  component  is  a  new  specification  of  a  smaller  part  of  the 
program.  The  design  also  describes  how  the  components  are  composed  so 
that  their  contributions  satisfy  the  original  specification.  In  the 
final  step  into  code  each  component  is  refined  until  it  may  be 
directly  expressed  in  terms  of  the  target  programming  language,  fit 
each  stage  of  refinement  correctness  is  assured  by  addressing  certain 
proof  obligations.  This  form  of  refinement  is  known  as  algorithmic 
ref i nement . 

Control  constructs 

□ur  design  will  be  expressed  using  the  generalised  control  constructs 
described  in  [CRIES  811.  these  constructs  are  not  part  of  the 
Z  language.  The  general  form  of  the  alternative  command  is 

if  — >  Si 
0  82 - >  S2 


Sn - > 

n  n 


Uhere  n  e  N. 

Informally  each  Bj  - >  Sj  is  a  guarded  command  one  of  which  may  be 

executed  if  the  guard  8^  is  true.  The  other  important  control 

construct  used  is  the  iterative  command.  The  general  form 
of  the  iterative  command  is 

do  Bj - >  Sj 

0  B, - >  S, 


0  B„ - >  S„ 

n  n 

ad 

Uhere  n  e  N.  Ue  shall  only  be  using  the  singleton  form  of  this 
command.  In  this  case  the  iterative  command  is  the  usual  notion  of  ths 
UHILE  00  construct  in  programming  languages. 

Design  refinement 

Since  REPEATER  was  specified  by  the  composition  of  REPEATERg  and 

CLEARDOUN  it  may  be  decomposed  into  the  sequential  composition  of  two 
program  operations  specified  by  these  schemas.  The  schema  REPEATERg 

was  itself  a  conjunction  of  the  two  schemas.  RECITE  and  OWERFLOU.  A 
natural  decomposition  of  REPEATERg  is  therefore  the  sequential 
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-  .  _..  _.  .<_w*.i.  Qiia  me  error  Handler  UUtRFLQU.  The  symbol 
denotina  refinement  is  C>  so  that  the  refinement  of  REPEATERg  may  be 

expressed  as 

■  REPEATERg  c  RECITE IQUERFLQU 

Note  that  sequential  composition  is  not  schema  composition^  it  Is  a 
composition  operator  of  a  proaram  desian.  Also  RECITE  and  OVERFLOW 
stand  for  operations  satisfyina  these  schemas.  Also  note  that  it  Is 
impossible  to  implement  REPEATERg  by  report ina  that  its  buffer  had 

overflowed  before  repeat ina  a  sinale  character.  This  is  because  to 
auarantee  refinement  certain  proof  obi iaat tons  must  be  addressed.  In 
this  case  they  are 

REPEATERg  c  RECITE lOUERFLOU 

if  and  only  if 

(1)  pre  REPEATERg  i-  pre  RECITE 

(2)  pre  REPEATERg  a  RECITE  i-  (pre  OVERFLOW)’ 

(3)  pre  REPEATERg  a  RECITE  a  DfERFLOU  i-  REPEATERg 1 

PI_’ ’/'_■]  is  a  notational  convention  renamina  all  variables  decorated 
with  a  sinale  dash  to  variables  decorated  with  a  double  dash 
The  pre  operator  aives  the  precondition  for  tt^e, schema  operation.  The 
precondition  in  2  is  someth ina  which  auarantees  that  a  final  state  can 
in  fact  be  reached  from  a  state  satisfyina  it.  These  theorems  are  easy 
to  prove  but  the i r "proofs  are  omitted  due  to  considerations  of  space, 
a  more  substantial  example  will  be  aiven  later.  The  overall  refinement 
so  far  is  the  followina. 

REPEATER  c  RECITE;OUERFLOU;CLEARDQUN 

Aaain  RECITE.  OVERFLOW  and  CLEARDOUN  are  operations  satisfyina  the 
schema  specifications.  The  first  operation  receives  characters  and 
re-transmits  them  at  some  later  time  until  some  error  occurs.  When 
this  happens  the  RECITE  operation  halts  and  an  error  is  reported  by 
OVERFLOW.  Finally  the  CLEARDOWN  operation  transmits  the  characters 
left  in  the  buffer. 

Because  RECITE  describes  the  operation  of  receivina  and  transmitt Ina 
characters  constantly,  a  natural  development  would  be  as  an  iterative 
command.  To  ensure  that  this  construct  behaves  in  the  way  described  by 
RECITE,  when  their  domains  aaree.  then  aaain  some  proof  obi iaat ions 
must  be  satisfied.  Normally  these  proof  obi iaat ions  would  include 
show ina  the  existence  of  a  measure  which  decreases  after  each 
iteration.  The  measure  auarantees  the  termination  of  the  loop  after  a 
finite  number  of  iterations.  The  specification  of  the  repeater  implies 
that  after  a  finite  number  of  characters  have  been  received  an  error 
occurs.  This  is  not  a  desirable  property  for  an  implementation  to  have 
so  the  proof  obi iaat ions  concern ina  The  boundedness  of  the  loop  are 
ianored.  With  this  simplification  the  proof  obliaations  for  the 
partial  correctness  of  a  refinement  are: 

RECITE  c  INV  ; 

do 

GUARD  - >  BODY  (Guarded  command  loop) 

od 

if  and  only  if 

(1)  pre  RECITE  h  preCINV  a  ■'GUARD'  ) 

(2)  pra  RECITE  a  INV  a  -^lUARD’  (-  RECITE 
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(3)  pre  RECITE  a  INW  a  GUARD’  K  (pre  BODY)’ 

(4)  pre  RECITE  a  INU  a  GUARD’  a  BODY’  h  INV[_”/_’] 

The  followins  schemas  define  the  guard  and  invariant  relation  which 
acts  as  an  initialisation  operation.  They  are  invented  and  then  then 
tried  to  determine  whether  the  proof  obligations  can  be  shown  to  hold- 
A  few  attempts  were  necessary  before  the  present  schemas  were  chosen. 

:>  GUARD _ _ 

I  buffer  :  seq  Char 
I  status  :  Input_status_reg i ster 


••buffer  <  max  a  status  ^  overflow 


INU _ 

I  i nput_trace’ .  output_trace’ .  buffer’  :  seq  Char 


input_trace’  =  output_trace’ ^buffer ’ 


The  body  of  the  loop  is  defined  by  taking  the  di'sjunction  of  three 
schemas  COLLECT.  TRANSniT  and  SKIP.  The  repeater  knows  when  a 
character  has  been  collected  at  the  input  port  because  the  input 
status  register  has  status  ’collect’. 

COLLECT _ , 

status  :  Input_5tatus_reg i ster 

char  ?  :  Char 

fiBUFFER 

^HISTORY 


status  =  collect 
buffer'  =  buffer''(char'’ > 
input_trace'  =  input_trace”<char? > 
output_trace’  =  output_trace 


The  operation  COLLECT  specifies  that  the  status  register  has  the  value 
’collect’  and  the  character  at  the  input  port  is  added  to  the  buffer. 
The  record  of  characters  received  is  updated  but  no  change  is  made  to 
the  record  of  characters  output. 

The  operation  TRANSHIT  specifies  that  the  status  register  for  the 
output  port  indicates  that  it  is  ready  to  receive  another  character. 
The  character  at  the  head  of  the  queue  is  recorded  in  the  output  trace 
but  the  input  trace  is  unaltered.  To  specify  the  TRANSHIT  operation 
the  output  port  needs  a  status  register.  The  status  signifies  when  a 
character  has  been  output  so  that  a  character  from  the  buffer  does  not 
overwrite  it  before  transmission.  Hence  the  set  of  values  for  the 
output  status  register  is  introduced  and  afterwards  the  particular 
value  ’empty’  is  declared. 

[Output_status_register ] 

empty  :  Output_status_reg i ster 
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TRflNSniT  _ 

status_o  :  □utput_status_reg i star 

char !  :  Char 

/^HISTORY 

liBUFFER 


status_Q  =  empty 

buffer’  =  taiKbuffer) 

char!  =  head(buffer ) 

output_trace’  =  output_trace'‘<char  I  > 

input_trace’  =  input_trace 


Finally  the  SKIP  operation  leaves  the  state  of  the  buffer  and  the 
traces  unchanged  whenever  the  status  of  the  output  port  is  unready  or 
the  status  of  the  input  port  is  not  collect.  For  example  if  the  output 
port  has  not  transmitted  all  the  bits  of  a  character  then  it  is  not 
ready  to  receive  a  new  character  from  the  buffer.  Similarly  the  input 
port  may  still  be  collecting  the  bits  of  an  incoming  character. 


status  :  Input_status_reg i ster 
status_o  ;  Qutput_status_reg i ster 
sHISTORY  . 

EBUFFER  ’ 


(status_o  X  empty  y  buffer  =  (>) 
status  =  ready 


The  meaning  of  the  s  operator  is  that  a  state  transformation  has  taken 
place  leaving  the  state  of  the  schema  unchanged.  The  previous  three 
schemas  define  the  body  as 

BODY  A  COLLECT  v  TRflNSnlT  y  SKIP 

The  following  propositions  discharge  the  proof  obligations  for  the 
refinement  of  RECITE.  The  first  proposition  ensures  that  there  exists 
a  state  where  both  the  invariant  relation  holds  and  the  guard  is 
false.  (The  precondition  of  a  schema  may  be  calculated  by  removing  all 
variables  ending  with  a  prime  or  shreik  ” ! ”  from  the  signature.  They 
are  then  renamed  and  existentially  quantified  in  the  predicate  part  of 
the  schema.  ) 

Proposition  1:  pre  RECITE  i-  pretlNU  a  ■’GUfiRD'  ) 

Proof : 

Calculating  preCINU  a  *<lUflRD’  )  gives 
preCINV  A  -CUfiRD’  )  = 

3  buff>  in/  out  :  seq  Char;  stat  :  Input _status_reg i ster . 
in  =  ouf'buff  A  (Xbuff  2  max  y  stat  =  overlfow) 

which  simplifies  to  true.  0 

The  next  proposition  ensures  that  RECITE  is  satisfied  if  the  loop 
term i nates. 


rs 

‘I 
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Proposition  Z:  pre  RECITE  a  INU  a  '•GUftRO'  y  RECITE 

Proof : 

Calculating  the  precondition  for  RECITE  and  conjoining  it  with  INU 
and  ■’GUfiRD*  gives 


/^BUFFER 

/IHISTORY 

status'  :  Input_status_reg i ster 


input_trace  =  <>  a  output_trace  =  <>  a  buffer  =  <> 
input_trace’  =  output_trace’''buffBr ' 

(••buffer'  2  max  v  status’  =  overflow) 

3  buf »  in.  out  :  seq  Char;  stat  :  Input_status_reg i ster . 
(••buf  2  max  v  stat  =  overflow)  a  in  =  ouf'buf 


which  may  be  simplified  to 


^BUFFER 

AHISTQRY 

status’  :  Input_status_reg i ster 


input_trace  =  < >  a  output_trace  =  (>  a  buffer  =  <> 
input_trace’  =  output_trace’ "“buff er  ’ 

(••buffer*  2  max  v  status’  =  overflow) 


which  is  the  same  schema  as  RECITE. 

0 


The  following  proposition  ensures  that  the  body  of  the  loop  is 
applicable  to  all  states  satisfying  the  invariant  relation  (in 
particular  the  states  satisfying  the  initialisation)  providing  the 
guard  allows  the  iteration  to  continue. 

Proposition  3:  pre  RECITE  a  INW  a  GUARD’  f  (pre  BODY)’ 

Proof : 

The  hypothesis  of  the  theorem  is  pre  RECITE  a  INU  a  GUARD’,  which  is 


^BUFFER 

^HISTORY 

status’  :  Input_status_reg i ster 


input_trace  =  (>  a  output_trace  =  <>  a  buffer  =  (> 
input_trace’  =  outpot_trace’ "buf f er ’ 

••buffer’  <  max  a  status’  *  overflow' 


(pre  BODY)’  is  equivalent  to  (pre  COLLECT  v  pre  TRANSMIT  v  pre  SKIP)’ 
These  preconditions  may  be  calculated  and  then  disjoined  to  give 


^ a..-i a n  ...n ».T  It-  n -  M-T  HT  >cr. (tn M-IT  K-l VJf  »J^KJnUlX^K»X5XT)tHXr 


status’  :  Input_status_re9 i star 
status_Q’  :  Qutput_status_re9 1  star 
buffar’  :  saq  Char 


status’  =  collact 

V 

(status_o’  =  ampty  a  «buffar’  *■  0) 

V 

(status_Q’^  empty  a  status’  =  ready) 

V 

(buffer ’=  <>  A  status’  =  ready) 


The  relevant  predicate  of  (pre  RECITE  a  INU  a  GUARD’  )  is 
(ttbuffer  <  max  a  status’>e  overflow).  To  prove  (  pre  BODY)’  a  case 
analysis  is  performed-  Since  the  value  of  status'  is  drawn  from  the 
set  Input_status_reg 1 ster  it  can  either  be  equal  to  ’ready’  or 
’collect’ . 

CASE  1:  Assume  status’  =  collect.  In  this  case  proof  of  (pre  BODY)’ 
is  immediate  because  the  first  disjunct  is  (status’  =  collect). 

CASE  Z:  status’?!  collect.  By  hypothesis  status’^?!Overf low  therefore 
status’*  ready  because  this  is  the  only  other  member  of  the 
set  Input_status_reg i ster . 

CASE  2A:  status’  =  ready  a  status_o’  =  empty- 
In  this  case  (pre  BODY)’  may  be  proved  if  ^buffer’  x  0 
”  -  because  of  the  second  disjunct  of  (pre  BODY)’.  If  ^buffer  =  0 

then  buffer  =  <>  and  therefore  the  fourth  disjunct  of 
(pre  BODY)’  is  true  because  in  this  limb  of  the  proof 
. .  .  status’  *  ready. 

CASE  ZB:  status’  *  ready  a  status.o’s*  empty. 

,  In  this  case  the  proof  of  (pre  BODY)’  is  immediate  because  of 

the  third  disjunct. 

All  the  possible  cases  have  now  been  exhausted  and  in  each  case 
(pre  BODY)’  has  been  shown  to  be  true.  D 

It  was  necessary  to  change  the  specification  of  SKIP  and 
Input_status_reg i ster  in  order  to  prove  the  previous  proposition.  For 
example  the  type  Input_status_reg i ster  was  previously  just  a  given 
set.  but  a  crucial  part  of  the  above  proof  is  the  fact  that  the  set 
contains  only  three  elements.  Hence  the  set  was  re-defined  to  make  it 
have  only  three  elements-  The  last  proof  obligation  ensures  that  the 
body  of  the  loop  preserves  the  invariant. 

Proposition  4;  pre  RECITE  a  INU  a  GUARD’  a  BODY’  i-  INU[_”/_'] 
i  Proof : 

i 

I  .  The  hypotheis  (pre  RECITE  a  INU  a  GUARD’  a  BODY’  )  may  be  calculated 

I  and  simplified  using  substitution  and  properties  of  sequences  to  give 

I  - 

I 

I 
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The  next  stage  in  the  development  of  the  design  is  to  refine  the  body 
of  the  previos  loop.  IF  -  FI  programs  often  arise  from  specifications 
of  the  form 

F  =  FI  V  FZ 

in  which  the  pre-conditions  of  the  disjuncts  are  characterised  by 
predicates  which  can  be  expressed  as  boolean  expressions  in  the  target 
language.  If  this  is  the  case  F  can  be  refined  at  once  into  the  IF  - 
FI  program  structure,  like  so: 

F  c  if  pre  FI  - >  FI 

0  pre  FZ  - >  FZ 

fi 


The  body  of  the  previous  loop  is  a  disjuction  of  three  schemas,  so  the 
body  may  be  refined  in  this  manner.  The  preconditions  for  the 
operations  COLLECT,  TRANSHIT  and  SKIP  have* been  calculated  earlier  so 


BODY 

c 

if  status  =  collect 
0  status_o  =  empty  a  “buffer  ^0 
0  (status_Q  X  empty  v  buffer  =  (>) 
A  status  =  ready 
f  i 


- >  COLLECT 

— >  TRANSMIT 

- >  SKIP 


.1 


me  operation  uvcrtr  i_uw  may  oe  rermeo  airecity  into  coae  so  tnis  is 
delayed  until  the  next  section.  The  operation  CLEARDDUN  takes  a  buffer 
that  has  overflowed  and  re-transmits  each  character  within  it.  The 
obvious  way  to  implement  this  is  using  a  guarded  loop  again.  This  time 
the  loop  must  be  shown  to  terminate  after  a  finite  number  of 
iterations.  The  guard  for  the  second  iterative  command  is 


^  C_GUARD 


buffer  :  seq  Char 


^buffer  >  0 

The  invariant 

for  CLEAROOWN  is 

C  TNU 

input_trace’ »  output_trace’ »  buffer’ 

:  seq  Char 

input_trace’  =  output_trace’ ''buffer  ’ 

The  body  of  the  iterative  command  is  defined  by  the  disjunction  of 
two  operations  TRANSHITZ  and  SKIPZ 


^TRANSniTZ 


status_o  :  0utput_status_re3 I ster 
char !  :  Char 

/IHISTORY 

^BUFFER 


status_o  »  empty 

buffer’  =  tail(buffer) 

char !  =  head (buffer  ) 

output_trace’  =  output_trace''(char  !  > 

input_trace’  =  input_trace 


VL’vvirov?vtfvyirgyi.^'TitncM>u/TgT[v^jriufK^  •vjnufrj(->rj(^.-\<niwrui 


■yirmrj<.m<iww  v.'wn^Jv»A#^-rf^.’v'jww-w".  V-  wj  rf-,-ir>  ir..  >«- . 


Pis  in  the  previous  operation  RECITE  there  are  proof  obligations 
including  obligations  to  show  that  the  command  will  terminate  after  a 
finite  number  of  iterations. 


CLEARDOUN  c  C.IN^  ; 

da 

C  GUARD - >  C_BDDY  (Guarded  command  loop  ) 

^  od 


if  and  only  if 


pre  CLEARDQUN  t-  pre  (C_INU  a  -C_GUARD’  ) 

pre  CLEARDQUN  a  C_INU  a  -•C_GUARD’  i-  CLEARDDUN 

pre  CLEARDQUN  a  C_INU  a  C  GUARD’  i-  bound_fuct  i  on  ( S’  )  2  0 

pre  CLEARDDUN  a  C_INU  a  C_GUARD’  i-  (pre  C_BDDY  )’ 

pre  CLEARDQUN  a  C_INU  a  C_GUARD’  a  C_BDDY’  i- 

[C_1NU 1  I  bound_funct ion(S’ ’  )  <  bound_funct i on ( S ’  )1 


where  S  a  liiHI STORY ;(1BUFFER] 
and  bound_funct ion  :  S  ■«  2 


The  proofs  of  these  theorems  are  similar  to  the  previous  set  which 
have  been  proved,  their  proofs  however  shall  be  omitted-  In  the  next 
section  the  design  is  assembled  and  implemented  in  C. 


THE  IMPLEMENTATION 


So  far  the  repeater’ has  described  its  function  at  a  character  level- 
Each  character  is  received  and  transmitted  at  a  port-  At  this  level 
the  character  is  dealt  with  as  a  series  of  eight  bits.  The 
specification  does  not  describe  the  bit  level  interaction  because  this 
is  dealt  with  by  the  hardware.  The  hardware  chosen  to  support  the 
implementation  is  the  hicrosys  UME  bus  system  incorporating  a  68010 
processor.  Assembling  the  components  of  the  design  for  the  repeater 

M  I  4 


S I  ves 


GUARD  - >  if  status  =  collect 

0  status_o  =  empty  a  abuffer  *  0 
0  (status_o  ^  empty  v  buffer  =  <>) 


- >  CDLLECT 

- >  TRANSniT 


a  status  =  ready 


- >  SKIP 


od: 

OUERFLOU; 

C_INU; 

da 

C_GUARD  - >  if  status_o  =  empty  a  buffer  ^  <)  - >  TRANBHITZ 

fl  status_o  ^  empty  - >  SKIPZ 

fi 

od 


These  non-determin ist ic  constructs  may  be  implemented  by  deterministic 
i f-then-else .  while-do  type  constructs  that  the  usual  programming 
languages  support.  Hence  a  possible  implementation  for  this  design 
could  be  the  following  C  program. 


adefine  PORT_A  OxF^OOOO  /*  Base  address  of  SID  Channel  A  */ 
adefine  P0RT_B  0xF400Z0  /*  Base  address  of  510  Channel  B  */ 
adefine  CHDREG  0x1  /*  Offset  of  Command  Register  */ 


"w  A*  ■w'jnunw  ->"\jr-jrrjr>ur 


^define  STflT_0  0x11 
^define  5TAT_1  0x11 
•♦define  DATA  0x13 


/*  Offset  of  status  Register  0  *7 
/*  Offset  of  status  Register  1  */ 
(*  Offset  of  Data  Register  */ 


••define  ioCport  fOffset  )  »(char  *  )(port+offset  ) 

/*  set  up  address  of  register  on  a  channel  correctly  */ 

••define  TRUE  1 
••define  FALSE  0 

••define  Hax  64  /*  Size  of  internal  character  buffer  */ 

int  start,  finish.  buffer_overf low.  bit_overflow; 

char  buffer [Max];  /*  Internal  buffer  */ 
char  c ; 

get()  -C  c  =  io(PORT_B.DATA);  > 

put()  <.  io(PORT_B.DATA )  =  c;  > 

pr i nterr ( str  ) 
char  str  C ] ; 

•C 

int  i  ; 

for  (  i  =0 ;  i  <  1? ;  i  ++  ) 

■C 

while  (  ( i 0 (PORT_A.STAT_0 )  &  4 )  ==  0 )  /*  output  not  ready  */ 

;  /*  wait  */ 

io(PORT_A.DATA )  =  strli];  ’  ’ 

> 

> 


V'  ■‘rm.'fn 


ma i n (  ) 

< 


int  i  ; 

i o (PORT_B.RCUCTL )  =  ’\301’;  /*  Set  up  Receiver  Ctrl  reg  on  B  */ 
io(PORT_B.XHTCTL )  =  ’\307’;  /*  Set  up  Transmit  Ctrl  reg  on  B  */ 
i 0 ( PORT_0 . CnOREG  )  =  ’\060’;  /»  Reset  Command  register  */ 

start  »  0; 
finish  a  0 ; 

for(i=0;  i<5000!  i-*"*-); 

/*  pause  to  ensure  initialisation  has  occurred  */ 

while  (  ((finish  +  1)  &  (Hax  -  1))  !=  start)  /^buffer  not  full  •/ 

&& 

( ( io(PORT_B.STAT_l )  &  3Z )  ==  0 )  /*  status  /=  overflow  •/ 


if  io(P0RT_B.STAT_0  )  &  1  !=  0  /*  status  =  collect  */ 

< 

get (  ) : 

buf fer [ f i n i sh ]  =  c; 

finish  =  (finish  +  1)  &  (Hax-l  )  /*f i n i sh: =f i n i sh+1  HDD  64  */ 

> 

else 

< 

if  (  ((io(P0RT  B.STAT_0 )  &  4)  !=  0)  /*  transmit  status  */ 

&& 

(start  !=  finish)  /*  non-empty  buffer  */ 


c  a  buf f er [start ) 
pu  t  (  ) ; 


start  =  (start+1  )  £  (Max-l  ); 

> 

> 

> 

if  (  ((start  +  1)  &  (flax  -  1))  ==  finish)  /*  buffer  full  */ 
■C 

pr inter r( "buffer  overflow\r\n"  ) 

> 

else 

■C 

pr interr ("bit  overflow\r\n"  ) 

> 

while  (start  !=  finish)  /*  while  the  buffer  isn't  empty  */ 

■C 

if  ((iQ(PORT  B»STAT_0)  &  4)  !=  0)  /*  transmit  status  */ 

< 

c  =  buf f er (start ] 
put (  ) ; 

start  =  (start+l  )  &  (Max-l  ); 

> 

> 


The  internal  buffer  is  implemented  by  a  charactfer  array.  The  array  is 
indexed  by  two  integers  denoting  the  start  and  finish  of  the  buffer. 
Addition  involving  these  integers  is  constrained  to  the  interval  zero 
to  sixty  three  by  a  bitwise  'and'  with  sixty  three.  In  other  words  the 
indexes  may  be  increased  modulo  sixty  three.  The  status  values 
correspond  to  certain  bits  being  set  in  a  register.  For  example  if  the 
register,  at  offset  STAT_0»  has  the  first  bit  set  then  a  character  has 
arrived  ready  for  collection. 

This  implementation  bears  little  resemblance  to  the  design  above. 
However  on  closer  inspection  it  can  be  seen  that  the  if-then-else 
construct  implements  the  alternative  construct  and  likewise  the 
while-do  for  the  iterative  command.  If  fragments  of  the  program  are 
examined  then  it  can  be  seen  that  they  implement  schema  operations. 

For  example  the  schema 

TRANSniTZ _ , 

status_o  :  0utput_status_regi ster 

char !  :  Char 

(IHISTORY 

(IBUFFER 


status_Q  =  empty 

buffer’  =  tail(buffer) 

char!  =  head ( buffer  ) 

output_trace’  =  output_trace'~(char  I  > 

input_trace’  =  input_trace 


may  be  implemented  simply  by 

•C  c  »  buf fer  (start ) 
put (  ) : 

start  »  (start+1)  &  (Max-1): 


The  trace  identifiers  are  not  implemented  of  course  since  they  are 
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records  of  the  characters  received  and  transm(tted.  However  the  output 
character  ' c'  does  become  the  head  of  the  buffer  and  the  buffer  does 
become  the  tail  of  the  buffer  by  incrementing  the  'start'  index.  The 
implementation  could  be  shown  to  be  correct  by  hand  using  pre  and  post 
conditions  derived  from  the  schema,  but  another  approach  is  taken. 

The  C  program  is  translated  into  IlftLPAS  IL  for  subsequent 
verification.  By  strategic  planting  of  assertions  derived  from  the 
design  and  specification  the  IL  may  be  verified.  The  IL  translation 
may  be., found  in  the  appendix.  The  assertions  at  the  two  loop  heads  are 
the  invariants  INU  and  C_INU.  Hence  the  invariants  from  the  design 
give  rise  to  the  loop  invariants  used  in  the  IL.  The  only  other 
assertion  in  the  main  part  is  the  post  condition  that  the 
input  trace  equals  the  output  trace.  This  is  simply  the  desired 
property  of  the  process  that  was  proved  in  the  second  section.  Note 
that  ’ input_trace'  and  ’ output_trace’  appear  in  the  IL  description  to 
describe  the  overall  state  of  the  process  that  was  implicit  in  the  C 
i mplementat i on . 

The  IL  listed  in  the  appendix,  along  with  the  appropriate 
declarations,  was  submitted  for  compliance  analysis,  fis  stated  in  the 
introduction  compliance  analysis  employs  semantic  analysis.  The 
semantic  analysis  of  the  program  together  with  the  assertions  gives, 
for  each  program  path,  the  circumstances  under  which  the  program  will 
violate  its  specification.  This  is  given  as  a  predicate  for  each  path 
and  the  disjunction  of  all  these  predicates  is  called  the  threat  to 
the  program.  For  example  the  threat  condition  pn.  the  path  from  the 
start  of  the  program  to  the  first  loop  head  is  given  by  the 
following  predicate. 

(1)  empty_sequence  *  convtoseqCbuffer .0.0  ) 

This  arises  because  the  assertion  at  the  first  loop  head  is 
* input_trace  =  output_trace*convtoseq(buffer .start .f i n i sh  .  Now 
input_trace  and  output_trace  have  been  initialised  to  empty_sequencE 
and  both  start  and  finish  were  initialised  to  zero.  Thus  the  assertion 
is  false  if  the  predicate  (1)  is  true  and  hence  this  is  a  threat  to 
the  program  satisfying  its  specification.  However  with  judicious 
replacement  rules  all  the  threat  conditions  can  be  shown  to  be  false. 
In  this  way  the  model  of  the  i mplementa i on  was  verified.  The  C 
program  was  compiled  and  ran  successfully  on  the  BBOlO  processor. 

CONCLUSION 

fl  method  has  been  presented  which  describes  a  software  repeater  as  a 
high  level  specification  and  enables  an  implementation  to  be  produced 
which  conforms  to  this  specification.  This  implementation  also  ran 
successfully  on  a  BBOlO  processor.  The  length  of  this  paper  is  due  to 
its  tutorial  nature.  In  the  development  of  a  system  details  of  the 
languages  Z  and  flflLPfiS  IL  would  be  omitted  along  with  details  of 
ref i nement . 

The  formulation  of  the  English  specification  into  Z  showed  many  areas 
of  uncertainty.  The  refinement  with  the  associated  proof  obligations 
also  fed  back  into  the  development  of  the  repeater  causing  cnanges  m 
the  design.  Tools  to  aid  specification  in  Z  and  a  proof  assistant  for 
Z  are  being  built  as  part  of  the  FDRE5ITE  project. 


vr.-...rj 


other  processor.  A  promising  topic  of  current  research  at  the  Oxford 
Programming  Research  Group  is  the  integration  of  CSP  and  Z.  The  use 
of  formal  methods  made  the  production  of  such  a  simple  program  more 
difficult  than  an  implementation  from  the  English  specification.  But 
by  use  of  formal  methods  correspondence  between  specification  and 
implementation  was  shown  as  well  as  properties  of  the  specification. 
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^  APPENDIX 

The  translation  of  a  program  into  hALPftS  IL  is  itself  a  form  of 
analysis  because  of  iL's  strong  typing.  For  example  bit  expressions  n 
C  are  implicitly  coerced  to  integers  if  the  identifier  on  the  left 
hand  side  of  an  assignment  has  type  integer.  In  IL  however  any  sucn 
coercion  has  to  be  explicit.  This  means  coercion  functions  have  to  be 
introduced  into  the  IL  description. 

To  aid  the  automatic  simplification  of  predicates  replacement  rules 
may  be  introduced.  For  example  to  simplify  the  threat  expresion 
given  at  the  end  of  section  three  the  following  replacement,  or 
rewrite,  rule  might  be  defined. 

REPLPCE  (b  !  char-array;  s.f  :  integer  ) 

convtDsep(b.s.f  )  BY  empty_sequencB  :  char-seduence  IF  s  =  f ; 

This  rule  introduces  bound  identifiers  b.  s  and  f.  These  bound 
identifiers  occur  in  the  expression  which  is  to  be  replaced,  namely 
’convtoseq(b.s.f  )' .  The  expression  will  be  replaced  by  empty_sequence 
only  if  the  integer  s  equals  the  integer  f. 

The  procedures  that  were  defined  in  the  C  program  may  be  translated 
into  IL  procedures.  These  may  be  defined  in  two  parts.  The  first  is 
the  PRCCSPEC  declaration,  this  specifies  the  procedure  in  terms  of 
input  and  output  variables.  The  second  part  defines  the  actual  body 
of  the  procedure  and  allows  the  verification  of  the  body  with  respect 
to  the  PRQCSPEC  declaration. 

The  following  is  the  IL  translation  of  the  C  program  given  in  section 
three  along  with  implanted  assertions. 

TITLE  repeater; 

TYPE  port,  char,  bits; 

TYPE  input_status  =  (ready .overflow. collect 

FUNCTION  input(bits)  :  input jstatus ; 

FUNCTION  output (bits)  :  boolean; 

CONST  max  :  integer  =  64; 

CONST  buffer_overflow  ;  chai — array  =  "buffer  over f low/R/N" ; 

CONST  bit_averflow  ;  char-array  =  "bit  over f low/R/N" ; 

CONST  revet  1  ;  bits  =  "OxD" 

CONST  xmtctl  :  bits  =  "0x8" 

CONST  stat_0  :  bits  =  "OxF" 

CONST  stat_l  :  bits  =  "0x11" 

CONST  data  ;  bits  =  "0x13" 

CONST  port_a  :  port ; 

CONST  port_b  :  port; 

FUNCTION  character (b I ts  )  :  char; 

FUNCTION  char_bits(char  )  :  bits; 

FUNCTION  int_hits( integer  )  :  bits; 

FUNCTION  bits_int(bits  )  ;  integer; 
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FUNCTION  convtoseqCchai — array, integer . integer  )  :  char-sequence; 
INFIX  debits. bits)  :  bits;  [Bitwise  find) 


FUNCTION  rw_i Q ( port ,b i ts,b i ts, i nteger  )  :  bits; 

[Read  or  write  to  port  at  offset  (:bits)  at  time  (: integer)  with 
value  ( : b I ts  )  ] 

REPLACE, (b  :  char-array;  s.f  :  integer) 

seq ( b  !  s  )“CQnvtoseq ( b >b  I  ts_i nt  (  i nt_b  i  ts( s+1  )&  i  nt_b  i  ts(63  )  ),  f) 

BY  convtoseq(b,s,f ); 

REPLACE  (i,  0  :  char-sequence ;b  :  char-array;  s,f  :  integer:  c  :  char) 
i*seq(c)  =  o‘convtoseq(  update(b,f ,c  ),s, 

b  I  ts_i  nt(  int_bits(f+l  )8iint_bits(B3  )  ) 

) 

BY  i  =  o*convtoseq(b,s,f ); 

REPLACE  (b  :  char-array;  s.f  :  integer  ) 
convtoseqCb.s.f  ) 

BY  empty_sequence  :  chai — sequence  IF  s  =  f ; 

FUNCTION  lengthCchai — array)  :  integer; 

PROCSPEC  io(IN  p  :  port  IN  offset  :  bits  INOUT  time  ;  integer 
INOUT  reg  :  bits) 

DERIVES  time  AS  time+1,  ’  ' 

reg  AS  rw_io(p, offset, reg, t ime ) 

PRE  true 

POST  (time  =  ’time  +  1)  AND  (reg  =  rw_i o ( ’  p , ’ of f set , ' reg , ’ t i me  ) ) : 

PROCSPEC  printerrdN  rep  :  chai — array  INOUT  i  :  integer) 

DERIVES  i  AS  i+lB, 

PRE  length(rep)  =  17 
POST  i  =  ’ i+lG; 

PROCSPEC  get (OUT  c  ;  char  IN  in  :  bits  INOUT  i  :  integer 
INOUT  tr  :  char-sequence ) 

DERIVES  c  AS  character (rw  io(port  b,  data,  in,  i  )), 
i  AS  I  +  1, 

tr  AS  tr  “  seq(character (rw_io(port_b,data, in . i ))) 

PRE  true 

POST  (c  =  character (rw_io(port  b,  data,  ’in,  ’i  ))  )  AND 
( i  =  ■ i  +  1  )  AND 

(tr  =  ’tr  *  seq(character(rw_io(port_b,data, ’ in, ’ i  )  ) ) ); 

PROCSPEC  put(IN  c  :  char  INOUT  i  :  integer  INOUT  tr  :  char-sequence) 
DERIVES  I  AS  I  +  1, 

tr  AS  tr  *  seq(c) 

PRE  true 

POST  ( I  =  ’ i  +  1  )  AND 

(tr  =  ’tr  *  seq(c)); 

riAINSPEC  (OUT  input_trace  :  char-sequence 
OUT  output_trace  ;  char-sequence 

) 

PRE  true 

POST  input_trace  =  output^trace; 
riAlN 

VAR  buffer  :  char-array; 

VAR  start,  finish  :  integer; 

VAR  status  :  bits; 

VAR  in  :  bits; 

VAR  i  integer; 


.3«-  ...  i  r  :..’=~- 


UflR  init_ctrl  :  bits; 
UAR  init_tran  :  bits; 
UAR  c  :  char ; 


input_trace  :=  empty_sequence  : 
output_trace  :=  enipt>'_sequence 
i 0 ( port_b /revet  1 / i / i n i t_ctr 1 ); 
i 0 ( port_b /xmtet 1 / i / i n i t_tran ); 
start  :=  0; 
finish  's-  0 ; 


ehar-sequenea ; 

;  ehai — sequenee; 


LOOR  ASSERT  input_trace  =  Qutput_trace'convtoseq( buffer /start / f i n i sh 
i o (port_b/Stat_l / i /status ); 


EXIT  UHEN  b i ts_i nt ( i nt_b i ts(f i n i sh+1 )  &  i nt_b i ts( max-1 ) )  =  start 
OR  I nput (status  )  =  overflow; 


io(port_b/Stat_0/ i /Status ); 

collect 


ENOLOOP ; 


IF  i nput ( status ) 

THEN 

set ( c / i n / i / i nput_tr ace ) ; 

buffer  :=  updatetbuf f er /f i n i sh/C  ); 

finish  ;=  b i ts_i nt ( i nt_b i ts (f i n i sh+1 i nt_b i ts (max-1  )) ; 

ELSE 

io(port_b/Stat_0/ i /Status );  ,  / 

IF  output (status )  AND  start  /=  finish 
THEN 

c  t=  buffer Istart ; 
put(c/ i /Output_tracB ); 
start  :=  bits_int(  i nt_b i ts(start+l )  & 
i nt_b i ts(max-l )  ); 

ENDIF; 

ENDIF; 


IF  bits  int(int  b i ts(f i n i sh+1  )  &  int_b' ts(max-l ) )  =  start 
THEN 

pr  i nterr (buffer  overflow/ i  ) 

ELSE 

pr I nterr (buffer  overflow/i) 

ENDIF; 


LOOP  ASSERT  input_trace  =  output_trace*convtoseq( buffer /star t / f i n i sh ) ; 


EXIT  UHEN  start  =  finish 

i o ( port _b /Stat_0 / I /Status ); 

IF  output (status  ) 

THEN 

c  :=  buffer  f start; 

Put (c/ I /Output_trace ); 

start  :=  bits  int(  int_bi ls(5tart*l )  &  i nt_b ' ts ( max-1  )  ); 
ENDIF; 

ENDLODP; 


ENDHAIN 


PRDC  io; 

reg  :=  rw_io(p/offset /reg/t ime  ); 
time  : =  time  +  1 ; 

ENDPROC ; 


PROC  get ; 

i 0 ( port_b /data .  i  /  in  ); 
c  character ( in ); 
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EXIT  WHEN 


ENDLODP; 

ENDPROC 


index  =  IG; 

c  :=  char_brts(rep! index  ); 
io(port_a,stat_0, i ,c ); 

index  :=  index  +  1; 


tr  :=  tr*seq(c  ); 
ENDPROC; 

PROC  put; 

UAR  d  :  bits; 
d  :=  char_bits(c); 
io(port_b,data. i ,d ); 
tr  :=  tr*seq(c  ); 
ENDPROC; 

PROC  pr intern ; 

'w^PR  index  :  integer; 
ypR  c  :  bits; 
i ndex  : =  0 ; 

LOOP 

PS5ERT  i  =  • i  +  inde> 


V^^l 


>  .  ■  •mm 


FINISH 
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